General: Forums subtopic: App & System Services > Networking DevForums tag: Network Extension Network Extension framework documentation Routing your VPN network traffic article Filtering traffic by URL sample code Filtering Network Traffic sample code TN3120 Expected use cases for Network Extension packet tunnel providers technote TN3134 Network Extension provider deployment technote TN3165 Packet Filter is not API technote Network Extension and VPN Glossary forums post Debugging a Network Extension Provider forums post Exporting a Developer ID Network Extension forums post Network Extension Framework Entitlements forums post Network Extension vs ad hoc techniques on macOS forums post Network Extension Provider Packaging forums post NWEndpoint History and Advice forums post Extra-ordinary Networking forums post Wi-Fi management: Understanding NEHotspotConfigurationErrorInternal forums post See also Networking Resources for general networking resources, including information about Wi-Fi. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I’m encountering a persistent issue with my Network Extension (specifically NEFilterDataProvider) and would really appreciate any insights. The extension generally works as expected, but after some time — especially after sleep/wake cycles or network changes — a global network outage occurs. During this state, no network traffic works: pings fail, browsers can’t load pages, etc. As soon as I stop the extension (by disabling it in System Preferences), the network immediately recovers. If I re-enable it, the outage returns instantly. I’ve also noticed that once this happens, the extension stops receiving callbacks like handleNewFlow(), and reinstalling the app or restarting the extension doesn’t help. The only thing that resolves the issue is rebooting the system. After reboot, the extension works fine again — until the problem reoccurs later. I asked AI about this behavior, and it suggested the possibility that the kernel might have marked the extension as untrusted, causing the system to intentionally block all network traffic as a safety mechanism. Has anyone experienced similar behavior with NEFilterDataProvider? Could there be a way to detect or prevent this state without rebooting? Is there any logging or diagnostic data I should collect when it happens again? Any guidance or pointers would be greatly appreciated. Thanks in advance!

We are using a Content Filter Network Extension to perform telemetry over the network activity of enterprise iOS devices. The filter itself is not blocking any connection. We encountered an issue where our Content Filter got stuck in a deadlock in the startFilter method of the NEFilterControlProvider. This resulted in a crash report where we see 64 threads stuck in the startFilter call. While the content filter was stuck in a deadlock, the device network connectivity was lost. We solved the deadlock issue coming from our logger, however, we would like to get a better understanding on the following points: What are the critical paths where a Content Filter can have a device wide impact on network connectivity? What is the behavior of the OS when the Content Filter is unresponsive (e.g. in startFilter, handle(Report), handleNewFlow)? Will it try to start the filter again? Force kill it ? We saw that startFilter was called multiple times in our crash reports whereas we expected it to be called only on vendor configuration changes. What is the lifecycle of the filter control provider and filter data provider ? When are the different methods like startFilter called ? We would like our Content Filter to never cause disruptions and implement a circuit breaker behavior in case any issue occurs. Do you have any recommendation on how to achieve this ?

We are using the NEHotspotConfigurationManager to programmatically connect to a specific Wi-Fi network for a limited period of time. From iOS 26, this now triggers a Passwords prompt asking the user if they want to save the Wi-Fi settings in the Passwords app. There are two problems with this:- We are temporarily connecting for a specific purpose and this network is not intended for the user to connect to again The prompt even appears if the credentials are incorrect and the Wi-Fi network cannot be joined While I can see some benefit to this dialog for a user connecting to a new network, it should not be displayed when programmatically connecting, or at least there should be the ability to disable it. Secondly, it seems like an obvious bug that the dialog is shown before the Wi-Fi connection successfully connects - why offer the user to store invalid credentials?

We are implementing a Transparent Proxy for HTTPS (via TCP and QUIC). The following rules are set in startProxy: settings.includedNetworkRules = [ NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), prefix: 0, protocol: .TCP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "::", port: "443"), prefix: 0, protocol: .TCP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), prefix: 0, protocol: .UDP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "::", port: "443"), prefix: 0, protocol: .UDP) ] Handling TCP connections seems to work fine. But opening UDP flows from Chrome (or Brave) always fails with Error Domain=NEAppProxyFlowErrorDomain Code=2 "The peer closed the flow" (Doing the same for Firefox works!) BTW: We first create a remote UDP connection (using the Network framework) and when it is in the ready state, we use connection?.currentPath?.localEndpoint as the localEndpoint parameter in the open method of the flow. Is it a known issue that QUIC connections from Chrome cannot be handled by a Transparent Proxy Provider?

We are developing a DLP agent that uses a NETransparentProxyProvider to perform traffic inspection and modification. Our architecture currently includes: LaunchAgent, which monitors user session activity (login/logout, session activation) Container App, which: installs and activates a System Extension creates and saves the NETransparentProxyManager configuration starts the transparent proxy via startVPNTunnel. We would like to automate the startup of the Transparent Proxy for all users, including newly created users, in a way that is fully supported by macOS. We are looking for official guidance on the correct and supported mechanism for starting a user‑level Network Extension (specifically NETransparentProxyProvider) automatically at user login. Questions: What is the recommended and supported way to automatically start a NETransparentProxyProvider at user login? Are there any constraints or best practices we should follow when designing an automatic startup flow for a Network Extension such as NETransparentProxyProvider? We would appreciate official clarification on the supported deployment patterns for starting a user‑level Transparent Proxy Network Extension automatically in multi‑user enterprise environments.

We got a feedback from apple side for our new request PIR server responded, but the canary value is not in the dataset. "www.apple.com/url-filter-test" should be set to 1 So we have validated this using our iOS app pointing to same environment and it is blocking this URL as per expectation as well as we have validated this using below curl docker exec pir-server sh -lc 'grep -n "www.apple.com/url-filter-test" /pir/data/input.txtpb; ls -l /pir/data/input.txtpb /pir/data/url-0.bin /pir/data/url-0.params.txtpb'; curl -sS -i https://ohttp.protectuswebfilter.com/.well-known/private-token-issuer-directory | sed -n '1,40p' Please help us, how they are validating this entry is available or not

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for one organisation app and it gets approved, so can I re submit the request with different bundle ID for other organisation and same PIR server, same OHTTP server ? Or do we need different domain name ?

We are building a NETransparentProxyProvider system extension on macOS. The extension needs a certificate identity provisioned by MDM for cryptographic operations at runtime (signing and/or mTLS). We have hit a wall where a PKCS#12-delivered identity resolves correctly inside the extension but an ACME-delivered identity does not, and we want to understand whether this is a known limitation, a gap, or whether there is a supported path we are missing. We understand the implications of the data protection keychain on macOS but wonder if there is a carveout here that may not be documented well. We deploy the extension via MDM (profile traditionally but could be via DDM on macOS27). A VPN profile delivers an identity reference to the extension at runtime via PayloadCertificateUUID which surfaces an identity reference within protocolConfiguration.identityReference. When referencing a PKCS#12 identity (com.apple.security.pkcs12 payload): the identityReference is 196 bytes, beginning with the 4-byte prefix 73737569 (ASCII "ssui"). The reference is self-describing — it embeds the keychain path (/Library/Keychains/System.keychain), the certificate subject (in our case, "Delegate Test CA"), the team ID, and a 20-byte SHA-1 hash at the tail. This format carries everything the Security framework needs to locate the item. Full reference (our test, redacted to structure): 73737569 00000020 <uuid-bytes> 00000000000000000000000000000006 64626e6d 00000023 2f4c696272…53797374656d2e6b6579636861696e00 ← /Library/Keychains/System.keychain 6974656d 00000069 80001000… ← item data incl. DER subject … 00000014 48b494ae47d1b7b07ed8c77a681337a3af8e92a8 ← 20-byte SHA-1 hash When referencing a ACME identity (com.apple.security.acme payload, ECSECPrimeRandom P-384, SE-backed): the identityReference is 20 bytes, beginning with the 4-byte prefix 63657274 (ASCII "cert"). The remaining 16 bytes are opaque — they do not embed a keychain path, certificate subject, or any other locator. Full reference (our test): 63657274 a4c7e569737944b1 ad464dc3bb398f14 Searching for the SecIdentity The PKCS#12 reference resolves using SecItemCopyMatching with kSecValuePersistentRef set to the 196-byte reference and kSecMatchSearchList pointing at System.keychain succeeds immediately, returning a SecIdentity with both SecIdentityCopyCertificate and SecIdentityCopyPrivateKey succeeding - this is obviously expected for an exportable software key type. The ACME reference fails using every path that we tried to search/load it as a SecIdentity. Primarily: kSecValuePersistentRef with kSecUseDataProtectionKeychain: true (no explicit keychain): -25291 (errSecNoDefaultKeychain) kSecValuePersistentRef with an explicit kSecMatchSearchList pointing at System.keychain: -50 (errSecParam) — combining kSecValuePersistentRef with an explicit keychain search list is an invalid parameter combination for the compact cert-format reference. kSecMatchItemList with an explicit kSecMatchSearchList: -25300 (errSecItemNotFound) SecKeychainItemCopyFromPersistentReference (legacy API): -25300 (errSecItemNotFound) kSecValuePersistentRef with no keychain qualifier at all: -25291 (errSecNoDefaultKeychain) com.apple.managed.vpn.shared access group (which i know has had entitled use on iOS): -34018 (errSecMissingEntitlement) Next steps The cert-format kSecValuePersistentRef produced by an ACME identity cannot be resolved in a root daemon context using any API path we can find. The ssui-format reference from a PKCS#12 identity works. With macOS 27, com.apple.configuration.network.vpn.vpn-plugin DDM declarations accept an Authentication.IdentityAssetReference which can point at an ACME identity asset. Traditional VPN profiles also support PayloadCertificateUUID referencing an ACME payload. Both paths result in the extension receiving a cert-format reference that it cannot resolve. Is there a supported API to resolve a cert-format kSecValuePersistentRef in a daemon context without a default keychain? Or is this just the reality of the DPK on macOS where ACME/SE-backed identities are not usable from system extensions, and the IdentityAssetReference and PayloadCertificateUUID fields only work for PKCS#12 or SCEP identity types in this context? For completeness: we have also explored ManagedApp.framework and ManagedAppIdentitiesProvider as an alternative delivery path, and believe this is the better method, but that hits a separate issue where managedappsd fails to verify the code signature of a system extension caller (filed separately as feedback FB23484530). Similar to this, we need to understand if the ExtensionConfigs in ManagedApp.framework are for appex user space app extensions only, and don't extend to System Extensions.

(Also submitted as FB23072541) iOS 27 beta 1 brings a brand new error which ends up resulting in a state of .serverSetupIncomplete: <NEPIRChecker: 0x7de6c79b60>: -[NEPIRChecker start:responseQueue:completionHandler:]_block_invoke - PIR status returned error <Error Domain=com.apple.CipherML Code=1100 "Unable to query status due to errors: Error details were logged and redacted." UserInfo={NSLocalizedDescription=Unable to query status due to errors: Error details were logged and redacted., NSUnderlyingError=0x7de712f4e0 {Error Domain=com.apple.CipherML Code=1800 "Error details were logged and redacted." UserInfo={NSLocalizedDescription=Error details were logged and redacted.}}}> <NEAgentURLFilterExtension: 0x7de6d24e60>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> What’s a NEMembershipChecker? Member of what? Digging deeper I found these: Failed to prefetch tokens for group 'site.kaylees.Wipr2': Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125a40 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} queryStatus(for:options:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125b00 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} The connection and the URL mentioned are fine of course, but "Network is down” now? This new problem only affects the App Store version of my app – not present if I install from Xcode. Users report that oddly, having an active VPN on the device works around this bug.

Hi, Our project is a MacOS SwiftUI GUI application that bundles a System Network Extension, signed with a Developer ID certificate for distribution outside of the app store. The system network extension is used to write a packet tunnel provider. The signing of the app & network extension is handled by XCode (v16.0.0), we do not run codesign ourselves. We have no issues with XPC or the system network extension during normal usage, nor when the application is installed on a user's device for the first time. The problem only arises when the user upgrades the application. I have experienced this issue myself, as have our users. It's been reported on Apple Silicon macbooks running at least macOS 15.3.2. Much like the SimpleFirewall example (which we used as a reference), we use XPC for basic communication of state between the app and NE. These XPC connections stop working when the user installs a new version of the app, with OS logs from the process indicating that the connection is immediately invalidated. Subsequent connection attempts are also immediately invalidated. Toggling the VPN in system settings (or via the app) does not resolve the problem, nor does restarting the app, nor does deleting and reinstalling the app, nor does restarting the device. The only reliable workaround is to delete the system extension in Login Items & Extensions, under Network Extensions. No device restart is necessary to garbage collect the old extension - once the extension is reapproved by the user, the XPC issue resolves itself. This would be an acceptable workaround were it possible to automate the deleting of the system extension, but that appears deliberately not possible, and requiring our users to do this each time they update is unreasonable. When the upgraded app is opened for the first time, the OSSystemExtensionRequest request is sent, and the outcome is that the previously installed system network extension is replaced, as both the CFBundleVersion and CFBundleShortVersionString differ. When this issue is encountered, the output of systemextensionsctl list shows the later version is installed and activated. I've been able to reproduce this bug on my personal laptop, with SIP on and systemextensionsctl developer off, but on my work laptop with SIP off and systemextensionsctl developer on (where the network extension is replaced on each activation request, instead of only when the version strings differ), I do not encounter this issue, which leads me to believe it has something to do with the notarization process. We notarize the pkg using xcrun notarytool, and then staple to the pkg. This is actually the same issue described in: https://developer.apple.com/forums/thread/711713 https://developer.apple.com/forums/thread/667597 https://developer.apple.com/forums/thread/742992 https://developer.apple.com/forums/thread/728063 but it's been a while since any of these threads were updated, and we've made attempts to address it off the suggestions in the threads to no avail. Those suggestions are: Switching to a .pkg installer from a .dmg As part of the .pkg preinstall, doing all of the following: Stopping the VPN (scutil --nc stop), shutting down the app (using osascript 'quit app id'), and deleting the app (which claims to delete the network extension, but not the approval in Login Items & Extensions remains??), by running rm -rf on the bundle in /Applications As part of the .pkg postinstall: Forcing macOS to ingest the App bundle's notarization ticket using spctl --assess. Ensuring NSXPCListener.resume() is called after autoreleasepool { NEProvider.startSystemExtensionMode() } (mentioned in a forum thread above as a fix, did not help.) One thing I'm particularly interested in is the outcome of this feedback assistant ticket, as I can't view it: FB11086599. It was shared on this forum in the first thread above, and supposedly describes the same issue. I almost find it hard to believe that this issue has been around for this many years without a workaround (there's system network extension apps out there that appear to work fine when updating, are they not using XPC?), so I wonder if there's a fix described in that FB ticket. Since I can't view that above feedback ticket, I've created my own: FB17032197

Hello, What are the restrictions on submitting apps to the mac App Store that use an NETransparentProxy alongside a locally installed and trusted Root-CA to intercept, decrypt and manipulate TLS traffic? To be more specific, I'm not talking about a Safari extension. I'm talking about system-wide traffic. So that the app can detect and block ads and trackers from all apps, not just Safari. I'm aware that such an app can be distributed using an unsandboxed Developer-ID signed app. But I wonder if such an app also breaks Sandbox requirements for AppStore distributed apps? Also, is there a way for a sandboxed app to install and trust a root CA? SecTrustSettingsSetTrustSettings does not work in Sandboxed apps from what I found. Finally, I want to ask about EndpointSecurity. Can this entitlement be used in AppStore-ditributed apps? Is doing any of these things possible on AppStore-distributed apps? Thanks in advance for your reply.

I'm building a gambling addiction recovery app for macOS that uses NEFilterDataProvider to block 208,000+ gambling domains system-wide. The app is already live on the iOS App Store under the same developer account. I need the restricted entitlement com.apple.developer.network-extension.content-filter to distribute via the Mac App Store. I submitted a request through Developer Support > Development and Technical Information > Rights/Entitlements (case #102914968660) on June 14th — 9 days ago with no response yet. My questions: Is this the correct channel for requesting this entitlement for Mac App Store distribution? Has anyone successfully obtained this entitlement? What channel/process worked for you? Is there a typical turnaround time I should expect? Any guidance appreciated. Thanks

Howdy, I've noticed a strange behavior recently on my macos (26.5.1) when using my System Extension-hosted Network Extension with a Packet Tunnel Provider inside: let dnsSettings = NEDNSOverHTTPSSettings(servers: ["8.8.8.8", "8.8.4.4"]) dnsSettings.serverURL = URL(string: "https://dns.google/dns-query") settings.dnsSettings = dnsSettings I have always expected this block to not need any DNS resolution, since IPs for dns.google are preconfigured, however not sure it's been the case lately. I see normal DNS requests to the addresses above to :53. Once resolved, no more DNS traffic, just :443 via TUN. Is it possible that some changes were introduced in the past months that would make macos to have to resolve dns.google with regular DNS before switching over to DoH?

macOS allows you to directly distribute a Network Extension using Developer ID signing, but with an important wrinkle. This post explains that wrinkle, its affect on Xcode, and how you get around it. If you have questions or comments, start a new thread here on the forums. Put it in the App & System Services > Networking and tag it with Network Extension. That way I’ll be sure to see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Exporting a Developer ID Network Extension macOS supports a variety of Network Extension (NE) provider types. Starting with macOS 10.15, it’s possible to distribute an app containing NE providers directly, using Developer ID signing. See TN3134 Network Extension provider deployment for the full list of supported provider types. For your NE provider to work when distributed directly, it must: Be packaged as a system extension. Use Developer ID specific entitlements This post is focused on that second point, because it’s a common source of confusion. Note If you’re currently shipping an app extension and you want to move to a system extension, see Network Extension Provider Packaging. This post assumes that you’re building your app with Xcode; if you’re building your app outside of Xcode, you’ll have to adapt these steps to your build system. Entitlement Matters A Network Extension system extension and its container app must be signed with the Network Extension entitlement (com.apple.developer.networking.networkextension). That entitlement is an array, with a variety of different element values based on the provider type. For example, a standard NE content filter provider must include the content-filter-provider value. There are two groups of these values: the standard ones and the ones with the -systemextension suffix. During development and for App Store distribution, use the appropriate standard value. For direct distribution using Developer ID, use the corresponding value with the -systemextension suffix. For example, a Developer ID signed NE content filter must use content-filter-provider-systemextension instead of content-filter-provider. Xcode Issues IMPORTANT Xcode 27.0b1 is reported to have fixed this issue, meaning that it should now be possible to export a Developer ID signed app with an Network Extension system extension from the Xcode organiser. I did some basic tests of that here in my office and it seems to work. Yay! So the following is only relevant if you have to build your app with an earlier version of Xcode. Xcode 26 and earlier are not aware of this requirement. If you build your NE provider container app using Xcode, you might expect to export it for direct distribution using the Direct Distribution workflow in the Xcode organiser. This does not work on older versions of Xcode (r. 108838909). To get around this, manually export your app from your Xcode archive. Before attempting that, there are a few things to confirm: By default Xcode’s Signing & Capabilities editor uses the standard values for the NE entitlement. Leave them that way. During day-to-day development it’s best to use an Apple Development signing identity [1], and the standard values work with that. Continue to use Build > Archive [2] to create an Xcode archive for your product. The steps below replace the Direct Distribution workflow, and they assume you’re starting with an Xcode archive. Note For hints and tips about how to bring up and then debug an NE provider, see Debugging a Network Extension Provider. [1] Don’t use Developer ID for day-to-day development; see The Care and Feeding of Developer ID for more on that topic. [2] Or, if you’re automating this, the archive action in xcodebuild. Assemble Your Assets Imagine you’re working on a content filter for the Mac called WaffleFilter. You’ve used Xcode to build the app into an Xcode archive: % ls "WaffleFilter.xcarchive/Products/Applications" WaffleFilter.app That app is development signed: % codesign -d -vvv "WaffleFilter.xcarchive/Products/Applications/WaffleFilter.app" … Authority=Apple Development: … … IMPORTANT The steps in this section are based on the much more comprehensive instructions in Creating distribution-signed code for macOS. If anything is unclear, read that documentation for clarification. To re-sign this app for direct distribution you’ll need three things: A Developer ID application signing identity. This is named Developer ID Application: TTT, where TTT identifies your team. A Developer ID provisioning profile for the app. In this example I’ve called this WaffleFilter_Dev_ID.provisionprofile. A Developer ID provisioning profile for the system extension. In this example I’ve named this WaffleFilter_WFProvider_DevID.provisionprofile. If you’re not sure how to create these things, see Developer Account Help. Re-sign the App To start, make a copy of the app: % ditto "WaffleFilter.xcarchive/Products/Applications/WaffleFilter.app" "WaffleFilter.app" Dump the entitlements of the app and its embedded system extension: % codesign -d --entitlements "WaffleFilter.entitlements" --xml "WaffleFilter.app" % codesign -d --entitlements "WaffleFilter_WFProvider.entitlements" --xml "WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension" And reformat them to make them more readable: % plutil -convert xml1 "WaffleFilter.entitlements" % plutil -convert xml1 "WaffleFilter_WFProvider.entitlements" Now edit these files to add the -systemextension suffix. The result will look something like this: % cat "WaffleFilter.entitlements" … <dict> … <key>com.apple.developer.networking.networkextension</key> <array> <string>content-filter-provider-systemextension</string> </array> … </dict> </plist> % cat "WaffleFilter_WFProvider.entitlements" … <dict> … <key>com.apple.developer.networking.networkextension</key> <array> <string>content-filter-provider-systemextension</string> </array> … </dict> </plist> Before you re-sign with these entitlements, replace the embedded provisioning profiles with their Developer ID variants: % cp "WaffleFilter_Dev_ID.provisionprofile" "WaffleFilter.app/Contents/embedded.provisionprofile" % cp "WaffleFilter_WFProvider_DevID.provisionprofile" "WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension/Contents/embedded.provisionprofile" Now re-sign the app and the system extension with their new entitlements, from the inside out: % codesign -s "Developer ID Application" -f --entitlements "WaffleFilter_WFProvider.entitlements" --timestamp -o runtime "WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension" WaffleFilter.app/Contents/Library/SystemExtensions/com.example.apple-samplecode.WaffleFilter.WFProvider.systemextension: replacing existing signature % codesign -s "Developer ID Application" -f --entitlements "WaffleFilter.entitlements" --timestamp -o runtime "WaffleFilter.app" WaffleFilter.app: replacing existing signature If you have multiple Developer ID Application signing identities, you’ll need to replace Developer ID Application with the name of the specific identity you want to use. IMPORTANT If your app contains other code items, like frameworks or an app extension, re-sign those as well. For advice on how to manually re-sign a more complex app, see Creating distribution-signed code for macOS. And you’re done! Manually Notarise Xcode’s Direct Distribution workflow also deals with notarisation. As you’re not using that workflow, manually notarise your app. For advice on how to do that, see Customizing the notarization workflow. You should also look at Packaging Mac Software for Distribution, which has a bunch of general info about packaging Mac apps. Revision History 2026-06-22 Xcode 27.0b1 is reported to have fixed this issue. Added information about that. Made other minor editorial changes. 2023-09-21 First posted.

I am testing NEURLFilter on macOS using the SimpleURLFilter sample, and I am seeing a failure from neagent while it is saving the local URL prefilter Bloom filter to its mmap file. The relevant log is: neagent +[NEBloomFilter mmapToFile:data:dataLength:numberOfBits:numberOfHashes:murmurSeed:tag:]: NEBloomFilter - failed to open mmap file /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.com.example.apple-samplecode.SimpleURLFilterTC3Q7MAJXF <errno 13 - Permission denied> neagent <NEAgentURLFilterExtension: 0xc8ce64280>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to save first fetch of pre-filter data Environment: macOS: 26.5.1 (25F80) Xcode: 26.5 (17F42) Platform: macOS Signing type: Apple Development (automatically manage signing) What I am doing: Build and run the containing app. Save and enable the NEURLFilterManager configuration. The URL filter provider starts. The provider's prefilter code is reached. neagent logs the mmap failure above while trying to open a temporary file under /private/var/db/urlPrefilter. Expected result: neagent should be able to create or open its system-managed URL prefilter cache / mmap file under /private/var/db/urlPrefilter, and the local Bloom filter should be loaded successfully. Actual result: neagent fails to open the temporary mmap file with errno 13 Permission denied: /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.<bundle/team-specific suffix> I am not manually creating, modifying, or chmod/chown-ing /private/var/db/urlPrefilter or anything inside it. The directory and its contents are entirely system-managed. The failure appears to happen inside neagent while it is handling the system-managed URL prefilter cache. The failure occurs at the mmapToFile: step while neagent saves the Bloom filter prefilter data. Directory state: drwxr-xr-x 2 root wheel 64 /private/var/db/urlPrefilter Has anyone else encountered this? Any suggestions on what could cause neagent to fail with errno 13 on its own mmap file under /private/var/db/urlPrefilter?

I haven’t been able to get this to work at any level! I’m running into multiple issues, any light shed on any of these would be nice: I can’t implement a bloom filter that produces the same output as can be found in the SimpleURLFilter sample project, after following the textual description of it that’s available in the documentation. No clue what my implementation is doing wrong, and because of the nature of hashing, there is no way to know. Specifically: The web is full of implementations of FNV-1a and MurmurHash3, and they all produce different hashes for the same input. Can we get the proper hashes for some sample strings, so we know which is the “correct” one? Similarly, different implementations use different encodings for the strings to hash. Which should we use here? The formulas for numberOfBits and numberOfHashes give Doubles and assign them to Ints. It seems we should do this conversing by rounding them, is this correct? Can we get a sample correct value for the combined hash, so we can verify our implementations against it? Or ignoring all of the above, can we have the actual code instead of a textual description of it? 😓 I managed to get Settings to register my first attempt at this extension in beta 1. Now, in beta 2, any other project (including the sample code) will redirect to Settings, show the Allow/Deny message box, I tap Allow, and then nothing happens. This must be a bug, right? Whenever I try to enable the only extension that Settings accepted (by setting its isEnabled to true), its status goes to .stopped and the error is, of course, .unknown. How do I debug this? While the extension is .stopped, ALL URL LOADS are blocked on the device. Is this to be expected? (shouldFailClosed is set to false) Is there any way to manually reload the bloom filter? My app ships blocklist updates with background push, so it would be wasteful to fetch the filter at a fixed interval. If so, can we opt out of the periodic fetch altogether? I initially believed the API to be near useless because I didn’t know of its “fuzzy matching” capabilities, which I’ve discovered by accident in a forum post. It’d be nice if those were documented somewhere! Thanks!!

Eons ago we were approved in the older entitlement method where we had to apply an Entitlement to our provisioning profile via a dropdown. We'd basically attach "Local Push Provider (Dist)" to our profile. That broke in May of 2025 when our fastlane process could no longer automate the creation of a provisioning profile with that profile attached. We learned the future was the capabilities so we submitted a request to migrate our Local Push Provider to a capability - https://developer.apple.com/contact/request/entitlement-migration-requests/ Meanwhile a new client wanted a white-labeled iteration of our app. So a new client requested the capability of Local Push via https://developer.apple.com/contact/request/local-push-connectivity and it worked in roughly 4 weeks. Their account now has "Network Extensions (additional values)" on the identifier which grants access to app-push-provider. Our build is fully automated - everything works. So we waited on our migration request and after months passed, we submitted in October of 2025 a new entitlement request for Local Push as our submit to migrate went stale. It never arrived again. So I started a case in 2026 roughly 6 months later - 102869206062. After many escalations I've been told: I wanted to provide an update to you regarding your entitlement request. It appears that your entitlement no longer requires a request. The channel you’ve reached is actually set up to provide administrative support to Apple Developers and those enrolled in the Apple Developer Program I just wanted to follow-up with you and ask you to please request the Network Extensions Entitlement again (19627183) It seems the overarching point is Network Extensions are no longer required for approval, but it seems app-push-provider (LocalPush) is. I don't want a random forum post to be a support thread. So looking for clarity on 2 points. Can you obtain app-push-provider (network extension) without Apple approval? Is this doc out of date? https://developer.apple.com/documentation/networkextension/local-push-connectivity To use the Local Push Connectivity API, your app must have the Network Extensions Entitlement with the app-push-provider value. Request this entitlement from the Entitlement Request Page. After you receive the entitlement, apply it to both your app target and your provider extension target. tldr; ➜ Desktop security cms -D -i match_ClientApp.mobileprovision| plutil -p - | grep 'push' 0 => "app-push-provider" ➜ Desktop security cms -D -i match_OurApp.mobileprovision| plutil -p - | grep 'push' ➜ Desktop

Hello, We have a security solution which intercepts network traffic for inspection using a combination of Transparent Proxy Provider and Content filter. Lately we are seeing reports from the market that on M5 Macbooks and A18 Neos the system will kernel panic using our solution, even though it never happens on M1-M4 and no significant code changes were made in the mean time. All crashes seem to be related to an internal double free in the kernel: panic(cpu 0 caller 0xfffffe003bb68224): skmem_slab_free_locked: attempt to free invalid or already-freed obj 0xf2fffe29e15f2400 on skm 0xf6fffe2518aaa200 @skmem_slab.c:646 Debugger message: panic Memory ID: 0xff OS release type: User OS version: 25D2128 Kernel version: Darwin Kernel Version 25.3.0: Wed Jan 28 20:54:38 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T6050 Additionally, from further log inspection, before panics we find some weird kernel messages which seem to be related to some DMA operations gone wrong in the network driver on some machines: 2026-03-30 14:11:21.779124+0300 0x30f2 Default 0x0 873 0 Arc: (Network) [com.apple.network:connection] [C9.1.1.1 IPv4#e5b4bb04:443 in_progress socket-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi, flow divert agg: 1, LQM: good)] event: flow:start_connect @0.075s 2026-03-30 14:11:21.780015+0300 0x1894 Default 0x0 0 0 kernel: (402262746): No more valid control units, disabling flow divert 2026-03-30 14:11:21.780017+0300 0x1894 Default 0x0 0 0 kernel: (402262746): Skipped all flow divert services, disabling flow divert 2026-03-30 14:11:21.780102+0300 0x1894 Default 0x0 0 0 kernel: SK[2]: flow_entry_alloc fe "0 proc kernel_task(0)Arc nx_port 1 flow_uuid D46E230E-B826-4E0A-8C59-4C4C8BF6AA60 flags 0x14120<CONNECTED,QOS_MARKING,EXT_PORT,EXT_FLOWID> ipver=4,src=<IPv4-redacted>.49703,dst=<IPv4-redacted>.443,proto=0x06 mask=0x0000003f,hash=0x04e0a750 tp_proto=0x06" 2026-03-30 14:11:21.780194+0300 0x1894 Default 0x0 0 0 kernel: tcp connect outgoing: [<IPv4-redacted>:49703<-><IPv4-redacted>:443] interface: en0 (skipped: 0) so_gencnt: 14634 t_state: SYN_SENT process: Arc:873 SYN in/out: 0/1 bytes in/out: 0/0 pkts in/out: 0/0 rtt: 0.0 ms rttvar: 250.0 ms base_rtt: 0 ms error: 0 so_error: 0 svc/tc: 0 flow: 0x9878386f 2026-03-30 14:11:21.934431+0300 0xed Default 0x0 0 0 kernel: Hit error condition (not panicking as we're in error handler): t8110dart <private> (dart-apcie0): invalid SID 2 TTBR access: level 1 table_index 0 page_offset 0x2 2026-03-30 14:11:21.934432+0300 0xed Default 0x0 0 0 kernel: [ 73.511690]: arm_cpu_init(): cpu 6 online 2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.511696]: arm_cpu_init(): cpu 9 online 2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.569033]: arm_cpu_init(): cpu 6 online 2026-03-30 14:11:21.934441+0300 0xed Default 0x0 0 0 kernel: [ 73.569038]: arm_cpu_init(): cpu 9 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.577453]: arm_cpu_init(): cpu 7 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.586328]: arm_cpu_init(): cpu 5 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.586332]: arm_cpu_init(): cpu 8 online 2026-03-30 14:11:21.934442+0300 0xed Default 0x0 0 0 kernel: [ 73.621392]: (dart-apcie0) AppleT8110DART::_fatalException: dart-apcie0 (<ptr>): DART DART SID exception ERROR_SID_SUMMARY 0x00003000 ERROR_ADDRESS 0x0000000000009800 2026-03-30 14:11:21.934443+0300 0xed Default 0x0 0 0 kernel: [ 73.621397]: Hit error condition (not panicking as we're in error handler): 2026-03-30 14:11:21.934443+0300 0xed Default 0x0 0 0 kernel: t8110dart <ptr> (dart-apcie0): invalid SID 2 TTBR access: level 1 table_index 0 page_offset 0x2Expect a `deadbeef` in the error messages below 2026-03-30 14:11:21.934452+0300 0xed Default 0x0 0 0 kernel: Expect a `deadbeef` in the error messages below 2026-03-30 14:11:21.934456+0300 0xed Default 0x0 0 0 kernel: (AppleEmbeddedPCIE) apcie[0:centauri-control]::_dartErrorHandler() InvalidPTE caused by read from address 0x9800 by SID 2 (RID 2:0:1/useCount 1/device <private>) 2026-03-30 14:11:21.934469+0300 0xed Default 0x0 0 0 kernel: (AppleT8110DART) Ignored dart-apcie0 (0xfbfffe18820b0000): DART(DART) error: SID 2 PTE invalid exception on read of DVA 0x9800 (SEG 0 PTE 0x2) ERROR_SID_SUMMARY 0x00003000 TIME 0x11242d43fd TTE 0xffffffffffffffff AXI_ID 0 We do not have any correlation between machines, usage pattern or installed applications. Uninstalling the network protection features seem to largely fix the issues, even though we have heard of crashes happening even in safe mode or with our network extension disabled from system settings. We weren't able to reproduce internally and it seems to happen completely random on client machines, but often enough to be disrupting. Can you tell us please if this is a known problem and if there's a workaround or what can we do to narrow it down? Thanks.

I've seen a number of similar posts from other network system extension developers reporting kernel panics on M5 devices in macOS. These kernel panics occur when network system extensions are enabled and are not observed on earlier mac platforms or versions of macOS. Reference: https://developer.apple.com/forums/thread/821372 In this post, it appears like Apple is aware of a problem as noted by Kevin Elliott in versions of macOS. Do we know if there is any way to work around this problem (short of not enabling a network filter) until a fix is available?

I would like to know whether it is possible to collect Wi-Fi signal strength on iOS 18 from an iPhone app. I need to measure Wi-Fi signal strength for an internal app. The app is not intended for App Store distribution. I enabled the Access WiFi Information capability and tested NEHotspotNetwork.fetchCurrent(). SSID and BSSID are returned correctly, but signalStrength always returns 0.0. Is there any official or supported way to get the current Wi-Fi RSSI/signal strength on iOS 18? For example, is this possible through NEHotspotNetwork, NEHotspotHelper, or any other iOS API?